Thanks for this — system proxy control is on the roadmap and the shape is useful.

This PR is currently conflicted/dirty against main after today’s iOS/quota merges, so I cannot run the normal local merge test yet. Please rebase/merge latest main into system-proxy and resolve the conflicts, especially around src/bin/ui.rs, src/lib.rs, and any Cargo changes.

Once it is clean, I will test it locally with at least:

cargo test --lib
cargo check --features ui --bin mhrv-rs-ui

For this specific feature I will also look closely at failure rollback: if the app exits or the command fails halfway through, it must not leave the user’s OS proxy stuck pointing at mhrv-rs.

Answered via LLM, Supervised @therealaleph

Thanks for the response.

I've merged the main branch into system-proxy and resolved the conflicts. Everything looks clean.
Also I've made sure to revert and clear system proxy settings when the app is exitting.

Thanks for rebasing this. I tested the PR head (0bd8731) locally:

cargo test --lib
249 passed

cargo check --features ui --bin mhrv-rs-ui
passed, warnings only

bash -n scripts/proxy_set_linux_sh scripts/proxy_set_osx_sh
passed

I am holding merge for now because this still needs a few safety fixes before we ship a system-wide proxy toggle:

1. We need restore semantics, not just "disable on exit". Right now on_exit() calls disable_system_proxy() unconditionally, and the clear path disables proxies for the machine/network services. If the user already had a corporate/custom proxy, or if another app configured one, mhrv-rs would wipe it on exit. Please snapshot the relevant previous proxy settings when enabling and restore only those settings, and only if this app successfully enabled the proxy.

2. The SOCKS fallback is wrong in Rust. cfg.socks5_port.unwrap_or(cfg.listen_port) should match the proxy server default (listen_port + 1) when socks5_port is unset. Otherwise the system SOCKS proxy points at the HTTP port.

3. The macOS script argument handling is off. set_proxy() reads $3 as SOCKS_PORT, but then does shift 2, so the SOCKS port also becomes the first bypass-domain entry. That should be shift 3 after the function consumes IP/HTTP/SOCKS.

4. The GNOME path sets org.gnome.system.proxy.socks port but never sets org.gnome.system.proxy.socks host, so SOCKS may be incomplete or inherit stale state.

5. The UI flips system_proxy = true before enable_system_proxy() succeeds and does not flip it back on error. Please update the UI state only after success, or explicitly restore it on failure.

The feature is useful, but because it changes machine-level network settings, I want the failure/restore behavior tight before merging.

Answered via LLM, Supervised @therealaleph